home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000058_news@newsmaster….columbia.edu _Tue Oct 7 01:40:29 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id BAA15739
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 7 Oct 1997 01:39:06 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id BAA17369
  7.     for kermit.misc@watsun; Tue, 7 Oct 1997 01:39:06 -0400 (EDT)
  8. Path: news.columbia.edu!news.cloud9.net!news-out.internetmci.com!newsfeed.internetmci.com!164.67.42.145!nntp.info.ucla.edu!134.87.113.1!news.bc.net!rover.ucs.ualberta.ca!alberta!not-for-mail
  9. From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Date: 06 Oct 1997 19:30:11 -0600
  13. Organization: University of Alberta, Computing Science
  14. Lines: 76
  15. Message-ID: <omvhza9x7g.fsf@tees.cs.ualberta.ca>
  16. References: <k1c7kBQEU5Wv@cc.usu.edu> <omraa16rl3.fsf@tees.cs.ualberta.ca>
  17.     <4TpKBo0duVW2@cc.usu.edu>
  18. NNTP-Posting-Host: tees.cs.ualberta.ca
  19. In-reply-to: jrd@cc.usu.edu's message of 5 Oct 97 08:40:36 MDT
  20. X-Newsreader: Gnus v5.0.15
  21. Xref: news.columbia.edu comp.protocols.kermit.misc:7829
  22.  
  23. In article <4TpKBo0duVW2@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  24.  
  25. Joe, the discussion is getting unnecessarily antagonistic, and I would hate
  26. that. I understand very well that you're the driving force behind MS Kermit,
  27. and I'm very grateful for what you've done for it. But I think that making it
  28. work with emulated class 1 (if possible and feasible) would make it slightly
  29. better. Of course, it should be first determined whether this is really a
  30. desideratum (that's why I asked what are the benefits of class 1, if any), and
  31. whether the effort required is worth it. Now, I know squat about TCP stacks,
  32. but I have this gut feeling (whatever that's worth) that it is something
  33. pretty small that prevents Kermit from doing it. After all, all the required
  34. functionality for class 1 is thre, and all the required functionality for
  35. serial line drivers is there.
  36.  
  37. If you decide such a task is worth pursuing, I'm offering my help with testing
  38. and experiments, and if you prefer, we can switch this discussion offline.
  39.  
  40. >     Class 1 Packet Drivers have no identification with "Internet"; we
  41. > presume that's your name for IP packets.
  42. Sorry, it's a typo, I meant Ethernet.
  43.  
  44. >     Again here are fundamentals and I hope you pause to understand this.
  45. > A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
  46. > the application protocol stack that Ethernet is the lan topology and hence
  47. > Ethernet rules apply.
  48.  
  49. Right. Something often used in the Unix world is "proxy ARPing". In that case
  50. a gateway host G that's connected to an ethernet and further to the internet,
  51. serves as a proxy to a client C that's connected to D through a PPP link. When
  52. another host X from G's ethernet ARPs with the IP of C, G returns its own MAC,
  53. and then takes care to forward any packets received as a result of that fake
  54. to C. (see eg http://www.med2000.com:457/NetAdminG/pppC.proxy_arp.html)
  55.  
  56. I don't know how do EPPPD and PPP -k 1 emulate class 1, but I suppose it's
  57. somethign similar.
  58.  
  59. > Amongst them are supporting MAC addresses, identifying stations in the same
  60. > broadcast domain
  61. Proxy ARPing makes C appear to be connected to G's ethernet.
  62.  
  63. > Frame construction is only part of the situation.
  64. It is my understanding that class 1 emulators do take care of ARP issues.
  65.  
  66. >     If a PPP or carrier-pigeon or whatever driver advertisizes itself
  67. > as Ethernet to the protocol stack then it must emulate Ethernet
  68. > characteristics to the protocol stack.
  69. Which ethernet characteristics do those emulators fail to emulate, and are
  70. they critical for the operation of a telnet application?
  71.  
  72. >     I have not the slightest idea of what code is in those programs. 
  73. > Have you looked at them to see what they do internally?
  74. No. I was hoping that we could determine what is the problem by looking at
  75. Kermit "from the outside" and/or by using some packet analyzers.
  76.  
  77. > > if one would like to use another TCP app together with Kermit, that app
  78. > > should also support class 6
  79. >     We do not support any attempt to run two TCP/IP stacks over the same
  80. > lan driver, period. Folks may be succussful at times with pktmux...
  81.  
  82. Consider this: a user may want to first run telnet, then close Kermit down and
  83. read their email using the same PPP connection. This is impossible if the
  84. telnet and the mail reader don't use the same driver class.
  85.  
  86. > > You seem to assert that class 1 emulating serial drivers are impossible,
  87. >     No such assertion has been made by me. You are the guy going to
  88. > extremes. 
  89. Ok, maybe I chose my words wrong, but what you've written so far is:
  90. - class 1 is supposed to work this way: <a non-technical description>
  91. - Kermit works ok with real class 1
  92. - ergo, there must be something wrong with class 1 emulators
  93. Of course, what I wrote isn't more technical either:
  94. - these other apps work with class 1 emulators
  95. - ergo, it should be easy to change Kermit to also work with them
  96.  
  97. > >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
  98. dosppp class 6 doesn't support it. How about MeritPPP class 6?